<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/html">
<head>
    <meta charset="UTF-8">
    <title>小谈项目配置</title>
    <link rel="icon" href="../../img/le.png">
    <link rel="stylesheet" type="text/css" href="../../vendor/bootstrap/css/bootstrap.min.css">
    <link rel="stylesheet" type="text/css" href="../../styles/common.css">
</head>
<body>

<div class="blog container-fluid">
    <div class="blog-header row text-center">
        <h3>小谈项目配置</h3>
        <div class="col-md-offset-7 text-left">
            -- 2017-01-17 于 soho
        </div>
    </div>

    <hr>

    <div class="blog-body row">
        <div class="col-md-offset-2 col-md-8">
            <h4>引言</h4>

            <p>项目开发中总是有各种各样的配置，对于程序开发新手来说，配置是摆在面前的第一座大山。
                回想当年在学校学习经典的“SSH”的时候，一个web.xml配置都是异常的艰辛。工作多年的你，对配置真的了解吗？</p>

            <h4>什么是配置？</h4>

            <p>首先我们来看一下配置文件的定义:
                <br><b><ins>“A software file used to configure the initial settings for a computer program.”</ins></b> -- From wikipedia
                <br>配置来源可能有以下这些:
            <ol>
                <li>硬编码参数</li>
                <li>项目里的配置文件</li>
                <li>文件系统上的配置文件</li>
                <li>网络上的配置文件</li>
                <li>启动参数（JVM属性）</li>
                <li>操作系统参数</li>
            </ol>
            </p>

            <div class="text-center">
                <img src="img/config.png" style="width: 375px;height: 400px;">
                <h6>(图一&nbsp;配置参数体系)</h6>
            </div>
            <p>下面会详细介绍每一种配置类型的使用场景。</p>

            <h4>硬编码参数</h4>

            <p>最常见的就是定义静态变量方式。例如：
                <code>
                    public static final int PAGE_SIZE = 10;
                </code><br>
                另外就是通过框架暴露的各种API接口设置参数。</p>

            <h5>优点</h5>

            <ul>
                <li>这种是最简单、成本最低的方式</li>
                <li>不用额外创建文件</li>
                <li>代码里能直接能读取</li>
                <li>离配置使用地方最近的一种方式</li>
            </ul>

            <h5>缺点</h5>

            <ul>
                <li>代码和配置糅合在一起，不易于维护</li>
                <li>修改配置必须修改源代码，重新编译、打包、上线</li>
                <li>同一个框架的配置散落到项目各个角度，不利于查找</li>
            </ul>

            <h5>适用场景</h5>

            <ul>
                <li>Hard Code 适用于配置极其简单且几乎不会变更</li>
                <li>为了赋予常量语义</li>
                <li>配置极少从而创建配置文件成本高</li>
            </ul>

            <h4>项目里配置文件</h4>

            <p>这种方式是最常见的。标准的maven项目有一个resources目录就是用来放置各种类型的配置文件，例如：
            <ul>
                <li>web项目的web.xml</li>
                <li>log框架的配置</li>
                <li>spring的bean定义的xml文件</li>
                <li>mybatis的sql配置文件</li>
                <li>spring boot的application.yml application.properties</li>
                <li>自定义的properties文件</li>
            </ul>
            </p>

            <p>另外maven项目的核心pom.xml也算是配置文件。项目里使用到的各种各样的框架、中间件基本上都需要配置文件来支撑。框架在运行时，读取配置文件来决定运行时的行为。
                配置文件路径一般有两种方式：
            <ul>
                <li>按照框架约定的目录（相对于classpath）</li>
                <li>告诉框架配置文件的路径</li>
            </ul>
            </p>

            <h5>优点</h5>

            <ul>
                <li>配置和代码分离</li>
                <li>集中统一管理配置</li>
                <li>不依赖项目外部资源</li>
            </ul>

            <h5>缺点</h5>

            <ul>
                <li>跟Hard Code一样不能动态修改配置</li>
                <li>配置文件增生，导致项目臃肿</li>
            </ul>

            <h5>适用场景</h5>

            <ul>
                <li>非常适合框架或者中间件的配置</li>
                <li>项目中自定义业务配置</li>
            </ul>

            <h4>文件系统上的配置文件</h4>

            <p>
                此类配置文件是放在应用运行的机器上。常见的比如携程公司内部机器上都会放置一个server.properties文件。文件内容主要是当前机器的一些信息，比如env=dev标示当前机器属于dev环境。公司配套提供framework-fundation基础jar包，用来解析这个文件。
                那么应用只要通过framework-foundation来获取机器的相关信息。
                framework-foundation在这里的作用就是作为机器和应用之间的桥梁。这种方式主要好处是规范运维。
                另外一种使用比较多的场景是应用直接读取文件系统上的某个文件。这种方式的好处就是可以动态更新配置，无需重新编译、打包、运行应用。</p>

            <h5>优点</h5>

            <ul>
                <li>配置和代码分离</li>
                <li>可动态修改配置</li>
            </ul>

            <h5>缺点</h5>

            <ul>
                <li>配置和应用代码不在一个地方（项目源码），不易于理解和运行</li>
                <li>修改配置需要登录机器</li>
                <li>修改配置文件可能涉及权限问题</li>
                <li>配置文件路径也需要沟通</li>
            </ul>

            <h5>适用场景</h5>

            <ul>
                <li>不建议作为应用业务相关的配置，成本高且不易于开发维护</li>
                <li>适用于运维相关的配置，如前面举的例子</li>
            </ul>

            <p>笔者遇到过一个dal框架，datasource配置文件就是放在文件系统上，结果开发人员在上线时，忘记在机器上放置这个文件导致线上bug。</p>

            <h4>网络上的配置文件</h4>

            <p>常见的包括两种：DB上的配置表、配置中心。如果公司没有统一的配置中心，那么最简单的动态修改配置的方式莫过于把配置放置在DB上。相信大部分的开发都使用过或者遇到过。
                配置中心是最适合集中化管理配置、动态修改配置的地方。常见的配置中心都会提供管理配置后台、实时推送配置、分环境管理配置、配置版本管理等。笔者目前就在开发一款开源的配置中心系统（<a
                        href="https://github.com/ctripcorp/apollo" target="_blank">携程Apollo配置中心</a>）</p>

            <h5>优点</h5>

            <ul>
                <li>集中管理配置、全方位管理配置</li>
                <li>动态修改配置、实时推送、更新配置</li>
                <li>配置更加灵活，例如可以分环境、集群以及灰度发布等</li>
            </ul>

            <h5>缺点</h5>

            <ul>
                <li>需要依赖数据库或者配置中心，成本高</li>
            </ul>

            <h5>适用场景</h5>

            <ul>
                <li>经常需要变更的配置</li>
                <li>配置值每个环境不一致</li>
                <li>不希望配置值随着代码一起发布，例如开源项目中的某些配置</li>
            </ul>

            <h4>启动参数（JVM属性）</h4>

            <p>
                JVM属性主要是应用运行的JVM进程相关的属性，比如java.class.version、java.class.path等Java相关的参数。在代码里，可以通过System.getProperty()获取参数值。
                另外，可以通过在启动时指定-D参数来设置JVM属性。最常见的使用场景是用来解决不同环境需要配置不同的参数。例如作为中间件，依赖的外部系统越少越好，如果不依赖配置中心，那么就可以通过这种方式来实现不同环境配置不同的参数，例如每个环境的数据库连接串不一样。
                另外需要提到的是maven打包参数。相比于-D运行时参数，maven打包参数是在编译时设置配置属性，maven会获取打包参数然后替换掉配置文件里的placeholder。假设一个可运行的jar包，只需要在打包的时候传入参数值，打出来的jar包就可以到处运行了，如果不这么做，那么需要每次运行的时候指定参数，成本太高。使用方式则是在mvn
                package 时指定-D参数。
                新手很容易混淆这两种参数。换个角度看-D是命令行参数。</p>

            <h5>优点</h5>

            <ul>
                <li>以非常小的代价就可以达到运行时指定特殊参数值</li>
            </ul>

            <h5>缺点</h5>

            <ul>
                <li>启动运行项目需要设置启动参数，增加使用成本</li>
            </ul>

            <h5>适用场景</h5>

            <ul>
                <li>适合中间件类系统，不推荐业务系统使用（业务系统用配置中心解决此类场景）</li>
                <li>增加统一运维成本</li>
            </ul>

            <h4>操作系统参数</h4>

            <p>操作系统参数一般是只读的，当然也可以设置。例如前面提到的server.properties文件里的env参数，其实也可以作为系统参数，但是不建议这么做。</p>

            <h3>后记</h3>
            <p>
                配置的好处显而易见，但是我们在工作中经常会遇到这种情况。拿到一个项目，看到乱七八糟的配置无从下手，项目中使用的框架、中间件配置风格更不相同，更头疼的是配置项如果不了解框架的基础上很难理解。导致的结果就是如果不复制、粘贴配置，手写配置基本上很难写对。
                验证这种情况最简单的方式就是不复制其它项目的配置，手动搭建一个新项目。我相信绝大多数的人都难以做到。</p>
            <p>片面的说学习一个框架其实是在学习这个框架的API和配置参数。如果你非常熟悉一个框架的配置，那么你对框架的使用就得心应手了。当然，知道框架的原理也非常重要。
                说这么多，只想说明项目的配置真的非常重要，更好的管理、规范配置更加重要。</p>
            <p></p>
            <p>对于框架、中间件开发者来说，配置应该越少越好，增加一个配置对于使用者使用成本就会大大提高。如果配置很多，那么你的框架基本上就是很难用了。
                Spring一直是Java界最权威的框架体系，最新的Spring Boot框架的配置就非常少，一眼看上去非常舒心。例如<a href="https://github.com/ctripcorp/apollo" target="_blank">Apollo项目。</a></p>
            <p>Spring现在倡导减少配置文件，例如Spring早期版本的xml配置其实是很繁琐的。新的Spring更多的配置放置在代码中，利用注解以及API方式配置。Servlet最新版本也不需要web.xml文件了。</p>
            <h4>说明一个道理: 大道至简？</h4>
        </div>

    </div>
</div>
</body>
</html>
